Nautilus 1992 July/Nautilus-3-8/Nautilus-3-8.bin/Tools & Utilities/Techy Stuff/Doco ƒ/CSMP ƒ/CSMP-V1-060.TXT

Text File | 1992-06-03 | 47.3 KB | 1,144 lines

C.S.M.P. Digest             Mon, 27 Apr 92       Volume 1 : Issue 60

Today's Topics:

    Help...Free-text DB for Mac (w. 4D ??)?
    Apple Event Manager & Threads & Futures Questions :-)
    Mac Programming
    INIT idea
    Summary of Think Pascal and MPW Object Pascal comparison
    Serial source code
    Looping Asynch Sound
    C++ exception handling (was: Zortech C++ Summary)


The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

These digests are available (by using FTP, account anonymous, your email
address as password) in the pub/mac/csmp-digest directory on ftp.cs.uoregon.
edu.  This is also the home of the comp.sys.mac.programmer Frequently Asked
Questions list.  The last several issues of the digest are available from
sumex-aim.stanford.edu as well.

These digests are also available via email.  Just send a note saying that you
want to be on the digest mailing list to [e-mail], and you will
automatically receive each new digest as it is created.

The articles in these digests are taken directly from comp.sys.mac.programmer.
They are not edited; all articles included in this digest are in their original
posted form.  The only articles that are -not- included in these digests are
those which didn't receive any replies (except those that give information
rather than ask a question).  All replies to each article are concatenated
onto the original article in the order in which they were received.  Article
threads are not added to the digests until the last article added to the
thread is at least one month old (this is to ensure that the thread is dead
before adding it to the digests).

Send administrative mail to [e-mail].

-------------------------------------------------------

From: [e-mail] (rodney jacks/vlk9)
Subject: Help...Free-text DB for Mac (w. 4D ??)?
Date: 23 Mar 92 22:11:21 GMT
Organization: Motorola Inc, Austin, Texas

>From: [e-mail] (Jyri Kuivalainen)
>Subject: Help... free-text DB for Mac (w. 4D ??) ?
>I am going to build a free-text database application with 4th
>Dimension in Mac-environment. The structure of the database will be
>close to the structure of encyclopedia: I have 1-3 indexed keywords
>and then variable-length text field (in 4th D. text field can contain
>max 36k characters, that is quite short).  In database seaches text
>portion will be heavily used. Database will be rather large, larger
>than 4D databases normally.

>Question: Is it reasonable to desing it this way? Are there any ways
>to speed up the seaches, I am afraid that a text search will not be
>fast enough? Am I banging my head against the wall? Is there some
>other way (tool) to build this? (I am very happy with pointers,
>commercials and ads).

You might do some background research into Bloom filters.  They
have been used in several free-text searching systems.  Essentially
they provide a cheap efficient (ie. insanely low memory requirement)
way of narrowing your search by creating signatures of the text records.
Then you search the signatures when looking for a keyword. If a
match occurs then you search the database looking at the appropriate
records/files pointed to by the signature.

If you are going to include a database engine in your application
you may have trouble tying the two together, but if your going to
build from scratch then definitely check them out.  If you would
like more info about them such as literature references send me a
message.

- -Rodney
***********************************************************************
**  Rodney Jacks                                                     **
**  Motorola Inc, Austin, Texas                                      **
**  E-mail:  [e-mail]                              **
**  Picard asks Worf what he thought of commanding the _Enterprise_  **
**  "Comfortable chair."     ST.TNG _The Emissary_                   **
***********************************************************************

---------------------------

From: [e-mail] (Gordon Watts -- U of Rochester)
Subject: Apple Event Manager & Threads & Futures Questions :-)
Date: 20 Mar 92 15:32:43 GMT
Organization: Fermilab

Hi all,
  I've been doing some research into Apple's unsupported Threads and Futures
package (see develop #6 and #7).  In the process of trying to understand how
the thing worked, I came up with a number of questions :-).  Ok, a lot of
questions.  9 of them.  They cover topics on the AE Manager, Futures, and then
the AE Manager again.

1). Does the Apple Event Manager always store replys in the reply ae you give
it in the AESend call?

    In inside mac vol 6, 6-64, they talk about an AESend with a timeout.
    If the server does not respond, AESend returns.  However, if the
    apple event comes in *after* this, it will still be put into the
    AppleEvent that was passed to AESend.  An error errReplyNotReady
    (or some such error message) will be returned if you try to access
    this reply before the reply has arrived at your application.

    The docs seem to reply this only happens when you specify a time-out
    value to AESend.  If I request the reply event to be queued, is it
    still stored in the AppleEvent I gave as the reply parameter to
    AESend?

    Is this one of the basic mechanisms that the threads package uses
    to implement futures?

2). What if I trash my reply apple event descriptor before the apple event
    returns?

    Lets say I send an apple event, with a timeout.  I've allocated both
    the apple event and the reply apple event on the stack.  I do an
    AESend, it times out, and I error out of the routine where these
    two apple event data structures were allocated.  I forgot to
    AEDisposeDesc them :-(.  Could this cause a subtle crash later in
    the program if the server does infact return a reply apple event
    later?  [Lets say I call another subroutine that uses the same stack
    space as the reply parameter -- so anything written there would
    override this routines local vars].

    Or does the apple event manager just use handles (in the apple
    event descriptor) so the stack is never touched?  It would mean that
    I had some extra memory that would never get deallocated, I suppose.

    What if I do a AEDisposeDesc function?  What happens when the reply
    comes in?  Does the AEM realize that I've disposed of the reply
    AppleEvent, and not save the data, or have I created a unreferenced
    handle?

3). Can I AEDisposeDesc a future?

    Do I block while trying to dispose of a future?  I hope not :-).  Is the
    dispose clean?  Will it release all the memory?

4). With futures, how do I get the AEResetTimer notifications?

    Lets say I do an apple event via the Ask function.  I block when I
    try to access the reply parameter.  I have a dream function installed
    for my thread -- to watch for a timeout.  What if the server app
    does a AEResetTimer call for this apple event?  How can I see that
    I should reset my dream proc timer?

5).  Is there any way to access the other parameters of the AESend routine when
using futures?

    I want to specify a queueing property, or a user interaction level
    and still want my reply to be a future.  Is there any way to do it?
    The Ask function only accpets an apple event, none of the other
    parameters.

6).  Back to straight apple events.  Is there a way to check if my reply
has arrived yet?

    Lets say I send, with a timeout value of 0 ticks.  I then want to
    know if my reply apple event has been gotten.  Is there a general
    way to do this?  Do I just have to access some random attribute and
    see if the error return is errReplyNotReady?

7).  How can I get the default reply event deep in my program.

    I see the AEGetTheCurrentEvent will return the apple event currently
being processed.  Is there any way to get the default reply event in a similar
manner?

8).  Is there any way to add something to the default apple event?

    If I would like the reply apple event to contain some tag, can I, as
the sender, modify the default reply apple event?  I notice the futures package
has some way of knowing when a future apple event reply comes in -- does it
remember transaction ids (or reply id), or does it add some tag to the reply
apple event?  I think the AEM calls some hook into the futures package.  Is
this a special handler (see next question)?

9).  What are special handlers?

    There is a special handler table -- written up at the very end of the
apple event chapter.  Two selectors are defined: keyPreDispatch and
keySelectProc.  Nothing is said about the routines you can define for them.
What are they?  What do they do, etc. etc.

Wow -- lots of questions.  Thanks for all your time!

    Gordon.

+++++++++++++++++++++++++++

From: [e-mail] (Greg L. Anderson)
Date: 24 Mar 92 02:15:36 GMT
Organization: Apple Computer Inc., Cupertino, CA

In article <+B+I+5![e-mail]> [e-mail] writes:
>Hi all,
>  I've been doing some research into Apple's unsupported Threads and Futures
>package (see develop #6 and #7).  In the process of trying to understand how
>the thing worked, I came up with a number of questions :-).  Ok, a lot of
>questions.  9 of them.  They cover topics on the AE Manager, Futures, and then
>the AE Manager again.
>
>1). Does the Apple Event Manager always store replys in the reply ae you give
>it in the AESend call?
>
>    In inside mac vol 6, 6-64, they talk about an AESend with a timeout.
>    If the server does not respond, AESend returns.  However, if the
>    apple event comes in *after* this, it will still be put into the
>    AppleEvent that was passed to AESend.  An error errReplyNotReady
>    (or some such error message) will be returned if you try to access
>    this reply before the reply has arrived at your application.
>
>    The docs seem to reply this only happens when you specify a time-out
>    value to AESend.  If I request the reply event to be queued, is it
>    still stored in the AppleEvent I gave as the reply parameter to
>    AESend?
>
>    Is this one of the basic mechanisms that the threads package uses
>    to implement futures?
>
>2). What if I trash my reply apple event descriptor before the apple event
>    returns?
>
>    Lets say I send an apple event, with a timeout.  I've allocated both
>    the apple event and the reply apple event on the stack.  I do an
>    AESend, it times out, and I error out of the routine where these
>    two apple event data structures were allocated.  I forgot to
>    AEDisposeDesc them :-(.  Could this cause a subtle crash later in
>    the program if the server does infact return a reply apple event
>    later?  [Lets say I call another subroutine that uses the same stack
>    space as the reply parameter -- so anything written there would
>    override this routines local vars].
>
>    Or does the apple event manager just use handles (in the apple
>    event descriptor) so the stack is never touched?  It would mean that
>    I had some extra memory that would never get deallocated, I suppose.
>
>    What if I do a AEDisposeDesc function?  What happens when the reply
>    comes in?  Does the AEM realize that I've disposed of the reply
>    AppleEvent, and not save the data, or have I created a unreferenced
>    handle?
>
>3). Can I AEDisposeDesc a future?
>
>    Do I block while trying to dispose of a future?  I hope not :-).  Is the
>    dispose clean?  Will it release all the memory?
>
>4). With futures, how do I get the AEResetTimer notifications?
>
>    Lets say I do an apple event via the Ask function.  I block when I
>    try to access the reply parameter.  I have a dream function installed
>    for my thread -- to watch for a timeout.  What if the server app
>    does a AEResetTimer call for this apple event?  How can I see that
>    I should reset my dream proc timer?
>
>5).  Is there any way to access the other parameters of the AESend routine when
>using futures?
>
>    I want to specify a queueing property, or a user interaction level
>    and still want my reply to be a future.  Is there any way to do it?
>    The Ask function only accpets an apple event, none of the other
>    parameters.
>
>6).  Back to straight apple events.  Is there a way to check if my reply
>has arrived yet?
>
>    Lets say I send, with a timeout value of 0 ticks.  I then want to
>    know if my reply apple event has been gotten.  Is there a general
>    way to do this?  Do I just have to access some random attribute and
>    see if the error return is errReplyNotReady?
>
>7).  How can I get the default reply event deep in my program.
>
>    I see the AEGetTheCurrentEvent will return the apple event currently
>being processed.  Is there any way to get the default reply event in a similar
>manner?
>
>8).  Is there any way to add something to the default apple event?
>
>    If I would like the reply apple event to contain some tag, can I, as
>the sender, modify the default reply apple event?  I notice the futures package
>has some way of knowing when a future apple event reply comes in -- does it
>remember transaction ids (or reply id), or does it add some tag to the reply
>apple event?  I think the AEM calls some hook into the futures package.  Is
>this a special handler (see next question)?
>
>9).  What are special handlers?
>
>    There is a special handler table -- written up at the very end of the
>apple event chapter.  Two selectors are defined: keyPreDispatch and
>keySelectProc.  Nothing is said about the routines you can define for them.
>What are they?  What do they do, etc. etc.
>
>Wow -- lots of questions.  Thanks for all your time!
>
>    Gordon.


- --
=====================   ===========================   =====================
Greg Anderson           Apple Computer, Inc.            O    Ponnuki    O
Macintosh Bodhisattva   Macintosh System Software      O O  is  ideal  O O
[e-mail]       Finder Team                     O     shape     O
=====================   ===========================   =====================

+++++++++++++++++++++++++++

From: [e-mail] (Greg L. Anderson)
Date: 24 Mar 92 18:39:58 GMT
Organization: Apple Computer Inc., Cupertino, CA

In article <[e-mail]> [e-mail] (Greg L. Anderson) writes:
[Useless waste of bandwidth deleted]

I replied to this message yesterday, but my news server decided to post
the unedited file instead of the version that contained my answers.  Sorry
for the wasted bandwidth; let's try it again:


In article <+B+I+5![e-mail]> [e-mail] writes:
>  I've been doing some research into Apple's unsupported Threads and Futures
>package (see develop #6 and #7).

I worked on the Threads & Futures package with Mike Gough, so I'll try
to answer your questions.

>1). Does the Apple Event Manager always store replys in the reply ae you give
>it in the AESend call?
[discussion deleted]

The AppleEvent manager copies the AppleEvent that you provide into a
heap object; you will not crash if you 'orphan' your stack-based AppleEvent
before the reply comes back.

This works because the AppleEvent contains a descriptor type (long word)
and a data handle (a pointer to a pointer to the actual data).  The AppleEvent
manager changes the data handle using its copy of the pointer to it.
Of course, you'll have a memory leak if you orphan the reply (since you
are supposed to dispose of it), but you don't have to worry about keeping
it on the stack all the time.  This is very important in the Threads package,
where the stack might not always be in the same place that it was when
the AppleEvent (future) was sent.

>    Is this one of the basic mechanisms that the threads package uses
>    to implement futures?

Yes, it is.  Additional (undocumented) support for futures was rolled
into the AppleEvent manager before it shipped.

>2). What if I trash my reply apple event descriptor before the apple event
>    returns?

If you called AEDisposeDesc you would be in trouble, but otherwise your
only problem would be with memory leaks (see answer to 1, above).

>3). Can I AEDisposeDesc a future?

No, you don't block if you dispose a future.  You should use the
DisposeFuture call rather than calling AEDisposeDesc directly.  I think
that the only consiquence of not doing so is a memory leak, but
offhand I'm not sure.  If you dispose of a future that has threads
blocked on it, all of the threads die (via EndThread).  If you call
AEDisposeDesc directly, they stay blocked (and you're likely to have
a memory leak).

>4). With futures, how do I get the AEResetTimer notifications?
>
>    Lets say I do an apple event via the Ask function.  I block when I
>    try to access the reply parameter.  I have a dream function installed
>    for my thread -- to watch for a timeout.  What if the server app
>    does a AEResetTimer call for this apple event?  How can I see that
>    I should reset my dream proc timer?

AEResetTimer doesn't work with futures.  This function extends the time
that a synchronous AESend will wait for a reply.  Futures return from
AESend immediately, though (since they are send with a timeout of zero--
kAEImmediateTimeout), so resetting the timer does not have any effect.

Read the section on dreaming in Develop #7 for the preferred method for
handling timeouts with Futures.

>5).  Is there any way to access the other parameters of the AESend routine when
>using futures?

You cannot specify a queueing property for a future.  Futures implicitly
use wait reply with kImmediateTimeout.  Anything else isn't a future.

It's bad that you can't specify a user interaction level, though, and
unfortunately you cannot just call AESend to make a future (more on this
in #6).

It's a bug.  I should fix it.

>6).  Back to straight apple events.  Is there a way to check if my reply
>has arrived yet?

If you send an AppleEvent in waitReply mode with any timeout value
(kImmediateTimeout is a good one, though), it will become a future
as soon as it times out.  This is important, because if you are using
the Futures package, accessing joe random property of the reply will
cause the future to block--but since the reply wasn't created with
the "ask" function, your future will not be correctly initialized.
Bad buju.

Looking at the code, it appears that nothing will happen, but you
probably won't get back the correct error result (which should be
errReplyNotReady).

This also looks like a bug that I should fix.  It looks like the error
returned will probably be kAEDescNotFound, but I haven't tried this myself.

>7).  How can I get the default reply event deep in my program.
>
>    I see the AEGetTheCurrentEvent will return the apple event currently
>being processed.  Is there any way to get the default reply event in a similar
>manner?

I don't know why you want to do this.  I've never used AEGetTheCurrentEvent
because I've never needed it--just use futures and pass the reply to any
function that needs it.

>8).  Is there any way to add something to the default apple event?

Short answer:  no.  There really isn't any such thing as a 'default'
AppleEvent.

>    If I would like the reply apple event to contain some tag, can I, as
>the sender, modify the default reply apple event?  I notice the futures package
>has some way of knowing when a future apple event reply comes in -- does it
>remember transaction ids (or reply id), or does it add some tag to the reply
>apple event?  I think the AEM calls some hook into the futures package.  Is
>this a special handler (see next question)?

When a reply comes in, the AppleEvent manager overwrites all information
in the AppleEvent that you supply with the contents of the reply.  The
exception to this is the "refCon" attribute of the AppleEvent, which isn't
really stored in the main AppleEvent structure anyway.  If an AppleEvent
you send has a refCon attribute, it's copied to the reply automatically.
There is no way for you to add information to the reply directly.

The futures package uses the refCon attribute, so your code will break if
you try to change the refCon of a future.

>9).  What are special handlers?

Special hanlders are handlers that are called in special circumstances.  :>

>    There is a special handler table -- written up at the very end of the
>apple event chapter.  Two selectors are defined: keyPreDispatch and
>keySelectProc.  Nothing is said about the routines you can define for them.
>What are they?  What do they do, etc. etc.

The PreDispatch handler is called for all AppleEvents before the event
is dispatched to its appropriate dispatch table.  However, system
pre-dispatch handlers are __only__ called if the event will not be handled
by any Application handler.  Application pre-dispatch handlers are
called even if a 'regular' handler will get the AppleEvent.

I don't know what a keySelectProc handler is for.

- --
=====================   ===========================   =====================
Greg Anderson           Apple Computer, Inc.            O    Ponnuki    O
Macintosh Bodhisattva   Macintosh System Software      O O  is  ideal  O O
[e-mail]       Finder Team                     O     shape     O
=====================   ===========================   =====================

---------------------------

From: [e-mail] (Bryan Socha)
Subject: Mac Programming
Date: 17 Mar 92 19:07:01 GMT
Organization: FidoNet node 1:273/921 - Unseen Realit, Philadelphia PA

I'm trying to get a basic skeleton program for use with system 7 and Think C
(or mpw)..  I seem to keep hitting bugs that I cannot understand (since I used
to be a ibm programmer and they're not bugs and I don't have time to relearn c
on mac).  I need something to allow easy adds into apple events for such
things as appletalk and program linking...

                                               Bryan

- --
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
 Bryan Socha - Internet: [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Tom West)
Date: 23 Mar 92 23:23:23 GMT
Organization: CSRI, University of Toronto


  Here's a general Mac programming question.

  I have a program that draws lots of lines and text.  It needs to draw
it to a window that will usually be the maximum possible size and
uncovered by any other windows.  Of course, it's always possible that
such might not be the case.  The user needs to be able to
see what's going on as the program draws, rather than just the end result.

  What I need to know is what is the best generic algorithm for doing this.
(I can't record the lines/text being drawn because it could be of any size.
The user could leave the program going on all night, for example.)
Here are some of the possibilities I see.

(1) Draw to a full size off-screen bitmap.  After every line, do a copy
    of the off-screen bitmap to the window with CopyBits.  Try to get the
    alignment right, etc.

    This is our present solution.  The only problem is that it's dead slow.

(2) Draw to a full size off-screen bitmap and draw to the window.

    Is this any faster?  The draw to the off-screen bitmap is okay because there
    never any clipping or anything, but would drawing the object to the
    window be faster than (1)?

(3) Draw to a full size off-screen bitmap and have a VBL task do the
    update from bitmap to screen every 15th of a second or so.

    This is complicated, (I haven't used VBL tasks before).  Is it worth
    it?

        Thanks in advance for any suggestions.
- --

    Tom West

   [e-mail]  or            "Into The Dark Lands"
[e-mail]  or          -Michelle Sagara
       [e-mail]

+++++++++++++++++++++++++++

Organization: Penn State University
Date: Tuesday, 24 Mar 1992 08:12:28 EST
From: Christopher Tate <[e-mail]>

In article <[e-mail]>,
[e-mail] (Tom West) says:
>
>(1) Draw to a full size off-screen bitmap.  After every line, do a copy
>    of the off-screen bitmap to the window with CopyBits.  Try to get the
>    alignment right, etc.
>
>    This is our present solution.  The only problem is that it's dead slow.

Right.  Having to do a CopyBits every time the image changes is icky.

>(2) Draw to a full size off-screen bitmap and draw to the window.
>
>    Is this any faster?  The draw to the off-screen bitmap is okay because    e
>ther
>    never any clipping or anything, but would drawing the object to the
>    window be faster than (1)?

Absolutely.  Drawing the line (or whatever) twice, once offscreen and
once on-screen, is almost certainly faster than drawing it once and using
CopyBits on the whole window.

>(3) Draw to a full size off-screen bitmap and have a VBL task do the
>    update from bitmap to screen every 15th of a second or so.

IMHO, it's not worth it.

Personally, I recommend using the offscreen bitmap for window refreshing
ONLY, and draw directly in the window whenever possible.  CopyBits is
fast for what it does, but it does an awful lot that you really aren't
worried about when you're drawing your objects.

I would go with (2):  each time you draw an object, draw it both to the
window and to the offscreen image.  If you ever have to update a region
of the window (as in response to other windows moving on top of yours, or
suchlike), use CopyBits to refresh the window's contents to match the
offscreen duplicate.

- -------
Christopher Tate     | Cryptogram #21:
[e-mail] |
[e-mail]  |  V MSD'B HQ HJCIQ.  V YBVRR XSPQ YCUQ MXQMIY RQTB.
- ---------------------|
Send me the answer!  |

+++++++++++++++++++++++++++

From: [e-mail] (Jon W{tte)
Date: 25 Mar 92 12:34:50 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

.csri.toronto.edu> [e-mail] (Tom West) writes:

   (1) Draw to a full size off-screen bitmap.  After every line, do a copy
       of the off-screen bitmap to the window with CopyBits.  Try to get the
       alignment right, etc.

Slow because you copy a lot of data.

   (2) Draw to a full size off-screen bitmap and draw to the window.

       Is this any faster?  The draw to the off-screen bitmap is okay because
       there never any clipping or anything, but would drawing the object to
       the window be faster than (1)?

If the object is just a line, polygon etc, its OK.
If you have a complicated object, copybits is faster.

   (3) Draw to a full size off-screen bitmap and have a VBL task do the
       update from bitmap to screen every 15th of a second or so.

VBL tasks may not call CopyBits, since CopyBits may move
memory. Instead, use the standard event loop and post an update
event every 15 seconds.

- --
[e-mail]; Jon W{tte, the Diplomat - NOT!

---------------------------

Subject: INIT idea
From: [e-mail] (Sauro Speranza)
Date: 23 Mar 92 10:12:21 +0100
Organization: Laboratory for Computer Science, University of Bologna, Italy

I've an idea for an INIT: it should patch the QuickDraw
initialization so that it believes the screen is 512x342
pixels, with 64 bytes per row, monochromatic, and install
a VBL which copies this pseudo-video RAM to the real video
RAM; or maybe create a "virtual" second screen with those
characteristics, anyway connected to the CRT through the
VBL.
I believe that with such an INIT many applications (mainly
games) which do not run in Mac IIs should succeed to run,
and since IIs are faster than a Plus or SE they should
run at a reasonable speed. But absolutely I haven't the
know-how to write it: is anybody willing to implement this
idea ?

- --
Sauro Speranza    e-mail: [e-mail]
            [e-mail]
Student in:
Computer Science, Bologna University

Mail address:
                  Sauro Speranza , via Cappuccini 18
                  40026 Imola   Italy
                  Tel  [phone]
                       (dall' Italia) 0542/45666
- --

+++++++++++++++++++++++++++

From: [e-mail] (Richard Chandler)
Date: 23 Mar 92 18:36:27 GMT
Organization: InterCon Systems Corporation

In article <[e-mail]>, [e-mail]
(Sauro Speranza) writes:
> I've an idea for an INIT: it should patch the QuickDraw
> initialization so that it believes the screen is 512x342
> pixels, with 64 bytes per row, monochromatic, and install
> a VBL which copies this pseudo-video RAM to the real video
> RAM; or maybe create a "virtual" second screen with those
> characteristics, anyway connected to the CRT through the
> VBL.
> I believe that with such an INIT many applications (mainly
> games) which do not run in Mac IIs should succeed to run,
> and since IIs are faster than a Plus or SE they should
> run at a reasonable speed. But absolutely I haven't the
> know-how to write it: is anybody willing to implement this
> idea ?

It's already been done.  There's a Cdev floating around out there called
MiniScreen that will let you set the screen size to any arbitrary size and a
number of pre-defined ones.

- --
People are more violently opposed to fur than leather, because it's safer to
harass rich women than biker gangs.
"Ride a motorcycle.  Save Gas, Oil, Rubber, Steel, Aluminum, Parking Spaces,
 The Environment, and Money.  Plus, you get to wear all the leather you want!"
 Rich Chandler, DoD #296

---------------------------

From: [e-mail] (Vasile R. Montan)
Subject: Summary of Think Pascal and MPW Object Pascal comparison
Date: 23 Mar 92 16:15:59 GMT
Organization: Concurrent Engineering Research Center

Below is the summary of the email I received in response to a request
for a comparison of Think Pascal and MPW Object Pascal.  Thanks again
to Ingemar, Peter Lau, Casgrain, Tommy and Peter Chang for taking the
time to respond.

- -----------------------------------------------------------------------------
From: [e-mail] (Ingemar Ragnemalm)

Think Pascal is easy to use and good for projects with one or few people
involved. I have used it on 1 meg plusses with comfort. (Havn't tried that
for the recent versions, though.) It is possible to run it on a floppy-
based system (as if anyone used that nowadays) and a 20-meg disk is more
than enough.

MPW is slower, bigger, harder to use, takes lots of space at least on
disk. However, it can be customized, extended and reconfigured in a way
that Think Pascal can't.

For both systems, a few extra megs of both RAM and disk is nice, but they
can be used on very small systems. I use Think Pascal on a SE 2/40 at home,
and that's no problem. (System 6.) With System 7, I'd recommend 4 megs.
No special hardware requirement, but MPW is a bit too slow on a Plus/Classic.

When comparing comfort, Think Pascal is a clear winner (as long as you
can stand auto-formatting of the code). It is fast and easy to develop
with it. The only real problem you may have is to learn what a "project"
file is - but it is much easier than Makefiles anyway.

MPW is for "power users". Definitely unsuited for casual users. It is
puzzling how something this "un-Mac-like" can be Apple's official platform.
No point-and-click, remember commands instead of recognition... I don't
like it at all.

So, if he will use it for his own personal projects, he needs Think Pascal.

- -----------------------------------------------------------------------------
From: [e-mail] (Peter Lau)

I have never used MPW Ojbect Pascal but I use MPW C and I do use
THINK Pascal and THINK C also.

MPW stuff is more expensive (~$300 vs. ~$170)

MPW is more unix-like (which is more confusing)
THINK is more Mac-like (which is loaded with other good stuffs)

MPW stuffs require at least 4MB and at least a 030 machine.
THINK requires 1-2 MB on any machine. (well, the faster the better, right?)

MPW is the official tool in Apple.
THINK is third-party vendor with a lot of happy users.  :-)

- -----------------------------------------------------------------------------
From: [e-mail] (Casgrain Philippe)

    Think Pascal (v4.0) is a fast and easy-to-use compiler. It is fairly
cheap (in terms of $$$) and can interface with the THINK Class library,
which contains a whole bunch ;) of useful routines. If you want quick
turnaround for your applications (i.e. minimal time from when you think of
the concepts to when it actually works), it's great.

    I personnally use MPW Pascal (v3.2, _not_ 4.0), and I love it, but
it costs many more $$$. Its main strenghts are in multi-developer projects.
But what I like the most about it is the MPW Shell, a powerful, unix-like
"editor": it does text in any way you want, and you can build a tool to do
what it does not.  Also, there is a scripting mechanism, which can allow
you to automate almost any task you do on the mac (I use it for backups).
    The MPW environment also supports various compilers (I have a
FORTRAN compiler to link old (1970) math routines in my Pascal programs).

- -----------------------------------------------------------------------------
From: [e-mail] (Tommy Nordgren)

I would strongly recommed your friend to chose Think Pascal.
1. According to news I've read, Think pascal compiles much faster than MPW.
2. Think is bundled with an application reading MPW pascal source code, and
   convert it to a form that can be used in Think Pascal. This will allow
   using source from both environments.
3. Think Pascal automatically maintains a file bescribing the dependencies
   between source file. This file is called a Project.
4. Think Pascal contains an integrated debugging environment, with a graphic
   user interface.
   The environment consists of following :
   When you are running under the environment, and stops at an error or
   breakpoint, a small hand icon points to the statement in the window
   containing the file (if is is open) or to the file name in the project
   window(if it is closed).
   A window called Observe. Here you can enter expressions,to be evaluated
    when a break occurs.
   A window called Lightsbug. Here you can inspect variables anywhere in the
   procedure call chain, inspect Heap Zones, inspect CPU registers,inspect
   inspect bytes at any memory adress. It is also possible to edit values.
   In the lightbug window you can also register varibles so that the debugger
   will be reentered each time one of them is changed.
    A window called instant -here you can enter pascal statements, to be
   executed at once.
5. Think Pascal in bundled with a main program file to use for debugging desk
    accesories.
6. Think Pascal is bundles with a class library for managing the graphic user
   interface. The Think Class Library require less memory , and probably are
   much easier to learn than MacApp from Apple.
7. Think Pascal stores libraries, in a format compatible with MPW libraries,
   and can read all Libraries Made under the MPW assembler. Some foreign
    libraries might be unusuable, because they contain references to the
   MPW runtime libraries.
I cant tell you much about MPW, except that the MPW environment uses a
COMMANDLINE Interface.
I am Currently using Think Pascal 3.0 so I cant tell what new features are
available under 4.0.
I would strongly recommend your friend to chose think Pascal.

- -----------------------------------------------------------------------------
From: [e-mail] (Peter)

    Here at Stanford the introductory CS classes are taught using
Think Pascal. The environment is really slick. It has a very nice
built-in debugger that lets you set stops, examine memory, and break
when conditions occur. It runs well on almost every macintosh model,
by this I mean that it runs slowly on an SE, but not unbearably so.
It also comes with think's object library, and a MacApp that has been
slightly modified. All in all it is a good environment.

    The only thing I know about MPW Pascal is that the compiler
is slow, and you still have to write makefiles and stuff. Think
takes care of all of this for you with its project structure.

---------------------------

From: [e-mail] (John Petrangleo)
Subject: Serial source code
Organization: Worcester Polytechnic Institute
Date: Mon, 23 Mar 1992 17:08:05 GMT

I am looking for some sample code to use the sserial ports
in my programs.  I am using Think C 5.0 and System 7.

What I need is:
    1)  opening the port (either one)
    2)  sending bytes
    3)  recieving bytes
    4)  closing the port

I don't need elegant code, I just need to see how it is done.
Thanks

- ---------------
[e-mail]
- ---------------

+++++++++++++++++++++++++++

From: [e-mail] (Glenn Austin)
Date: Wed, 25 Mar 92 01:13:22 PST
Organization: The Pit Lane


In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (John Petrangleo) writes:
> I am looking for some sample code to use the sserial ports
> in my programs.  I am using Think C 5.0 and System 7.
>
> What I need is:
>     1)  opening the port (either one)
>     2)  sending bytes
>     3)  recieving bytes
>     4)  closing the port
>
> I don't need elegant code, I just need to see how it is done.

How's this for simple (yes -- this is simplified C for the Pascal programmers
out there):

- ---
short        toolID;
ConnHandle    hconn;
CMBufferSizes    bufSiz;

(void) InitCRM();
(void) InitCTBUtilities();
if (InitCM())
    return();

toolID = CMGetProcID("\pSerial Tool");
if (toolID == -1)
    return();        // serial tool wasn't found!

{
    short    i;

    for (i = cmDataIn; i <= cmRsrvOut; ++i)
        bufSiz[i] = 0;
}

hconn = CMNew(toolID, cmData, bufSiz, 0, 0);
if (hconn == nil)
    return();        // failed to create conn record

                // configure the port...
if (CMSetConfig(hconn, "Baud 9600 dataBits 8 Parity None Port \"Modem Port\""))
{
    CMDispose(hconn);
    return();
}
                // or -- you could use CMChoose to let the
                // user configure the tool they way they
                // need it...

if (CMOpen(hconn, false, nil, 0))
{
    CMDispose(hconn);
    return();
}

// read and write to your heart's content using CMRead and CMWrite

(void) CMClose(hconn, false, nil, 0, false);

CMDispose(hconn);

- ---
The advantage to using the CTB is that you can make connections over ADSP,
TCP/IP, Telnet, and so on without changing a line of code...

Remember, there are getting to be more people out there with more than two
serial port (or at least devices which act as serial ports)!!!  Don't make
us hack more code to get your program to work on our hardware!  (Hear me,
Apple Print Shop and Remote Access teams!?!)


===============================================================================
| Glenn L. Austin                | "Turn too soon, run out of room.           |
| Macintosh Wizard and           |    Turn too late, much better fate."       |
| Auto Racing Driver             |   -- Jim Russell Racing School Instructors |
| Usenet:  [e-mail] or [e-mail]    |
===============================================================================

---------------------------

From: [e-mail] (Brendan Duddridge)
Subject: Looping Asynch Sound
Date: 23 Mar 92 19:04:22 GMT
Organization: University of Manitoba, Winnipeg, Canada

Hi.  I've been trying to get Asynchronous sounds to work on my Macintosh IIsi
in Think Pascal 4.01.  I have successfully created an animation that plays
while a sound is playing.  No problems there.  What I'd like to know is how
can I get the sound to keep looping and stop only when the user presses the
mouse button?  I keyed in the UAsynchSound unit from the Usenet Macintosh
Programmers Guide.  I think it was written by Leonard Rosenthal at Apple.
Anyway, It crashes whenever the sound stops playing.  The callBack routine
seems to be causing a Bus error and my Mac pops into MacsBug.  What I was
attempting to do was find out when a sound had stopped playing so I could call
SndPlay again to loop it.  Any ideas?  I'm running System 7.01 w/ TuneUp.

Thanks...
- --
Brendan Duddridge
InterNet        : [e-mail]
America Online  : BrendanD1

+++++++++++++++++++++++++++

From: [e-mail] (Jochen Meyer)
Date: 25 Mar 92 13:43:25 GMT
Organization: University of Oldenburg, Germany

[e-mail] (Brendan Duddridge) writes:

>mouse button?  I keyed in the UAsynchSound unit from the Usenet Macintosh
>Programmers Guide.  I think it was written by Leonard Rosenthal at Apple.
>Anyway, It crashes whenever the sound stops playing.  The callBack routine
>seems to be causing a Bus error and my Mac pops into MacsBug.  What I was

You possibly  didn't switch off the debug and other checking options for
the callback routine. This is absolutely necessary, since the debug code
seems to do things that are not allowed at interrupt time.

Using something like
   {$PUSH}
   {$D-}
   (other options)
   (callback procedure)
   {$POP}
should help (at least it did, when I had the same problem).

Jochen


- --

**************************************************************************
*                      Jochen Meyer                                      *
*          Tel. (Germany) 0441 / 508547 (voice)                          *
*                                                                        *
* inHouse: faustus@faramir                                               *
* email:   [e-mail]                 *
**************************************************************************

---------------------------

From: [e-mail] (Joe Francis)
Subject: C++ exception handling (was: Zortech C++ Summary)
Date: 24 Mar 92 07:34:30 GMT
Organization: Dartmouth College, Hanover, NH

In article <[e-mail]>
[e-mail] (John Nagle) writes:

> With some work, Symantec could leapfrog MPW and bring C++ up to the
> level documented in Strostrup's latest definition of the language.
> C++ with exceptions, and classes that use them properly to protect
> themselves, could provide a much more reliable support structure for
> Mac programs.  This might provide a path out of the general flakeyness
> of Mac programs.

Much to my pleasant surprise, I discovered that it is not that
difficult to implement your own try/catch-like exception scheme for MPW
C++.

Just have every "try" initialize an "exception scope" when at the
beginning of the block, and clean it up at the end.  Every catch also
cleans up the "scope", too.

Derive all of your objects (or all of your non-Handle-based objects, or
whatever subset of your objects you want this to work for) off of a
root class.  This root class has code in it's constructor to interact
with your exception code that, specifically, instantiates a linked list
element that associates your new object with the current exception
scope.  The destructor does the reverse, of course.

When you reach the end of a "try" block (success!) any items left on
the current scope's list get appended on to the list of the next scope
up, if any.  Of course, if all the objects that were using this scheme
were stack based, then there won't be any items in the list when you
reach the end of the try block - all the stack based objects in that
block (and any called by it) already automagically had their
destructors called, and hence removed themselves from the list.

The case for the "catch" is pretty much the same (remaining objects
about to outlive their scope are handed off to the parent scope), but
some important work has occurred before the "catch" is ever reached.
When an error occurs, and a "throw" is called, the throw code walks the
list associated with the current exception scope and destroys all the
associated objects.  (Note that this must happen before the longjmp
back to the "catch", otherwise any stackbased objects become invalid
and cannot safely be destroyed.)

That's all there is to it, as far as the basics go.  There are some
things to note:

* The basic try/throw mechanism is based on setjmp/longjmp,  which are
described in K&R C and also the MPW C documentation.

* I made no attempt to imitate the "typing" of catch statements
described in C++PL, 2nd edition.  I didn't need this, and I don't think
it can be cleanly done without the compiler's support & TLC.

* Yes, this will exact a performance penalty.  If you want to use
20,000 stack based objects in a try-scope, you'll eat up space and
time.  My use of objects is not so extreme as to cause any noticeable
degradation.

* I wanted to get let the programmer have some control, on an object by
object basis, how it interacted with the exception code; and I wanted
different types of objects to have different types of default behavior.
 Stack based objects go onto the current scope by default, heap based
objects do not play the game by default.  This means that the root
class constructor has to figure out if an object is on the stack.  The
following macros have worked for me (and *please* let me know if they
are faulty):
#define
ONSTACK(a)(((long)(a)<=*(long*)CurStackBase)&&((long)(a)>*(long*)ApplLim
it))
#define INHEAP(a)
(((long)(a)>=*(long*)ApplZone)&&((long)(a)<*(long*)HeapEnd))

* The code that deletes all the objects on a scope list during a
"throw" has to figure out whether it stack or heap based no matter
what, of course, so that it can properly delete it.  If it's heap based
you "delete object;", but if it's stack based, you
"object->RootObject::~RootObject();".  At least that's what you do with
MPW C++ 3.x.  I've examined the intermediate code and verified that
these two methods of deletion generate exactly the same code, except
for a flag argument that tells the destructor whether or not to do a
"free" on the object's 'this' pointer.  Note that the
"object->RootObject::~RootObject();" call still exercises virtual
destructors.  This was not obvious to me at first, especially since the
same syntax with any member function other than a destructor will not
result in virtual member functions of child classes being honored.
Fortunately the destructor syntax works differently.  (The syntax you
might think was most natural, "object->~RootObject();", is just plain
illegal for reasons I don't understand.)

* Use different keywords than "try" and "catch" - MPW C++ treats these
as key words reserved for future use.  I used "ATTEMPT" and "RECOVER".
(I know, no imagination.  I should have used "SOYBEAN" and "POWERTOOL",
or maybe "QUAYLE" and "BARBARA".)

* The best part about all of this is that you then control the
exception handling functionality. You can't easily add support for,
say, error alerts (or notifications if you are in the background at the
time) to the try/throw/catch mechanism that will eventually be supplied
with MPW C++ version 17.0, but you can throw the whole kitchen sink
into your own exception code, if you so desire.

I want to encourage people to try this sort of thing if they are
hurting (like I was) for a throw mechanism that cleans up orphaned
objects.  It really didn't turn out to be as big a job as I thought.
You write a little code, you change all your favorite base class
declarations to hang off of RootObject, and your off!

+++++++++++++++++++++++++++

From: [e-mail] (Greg L. Anderson)
Date: 24 Mar 92 21:21:03 GMT
Organization: Apple Computer Inc., Cupertino, CA

In article <[e-mail]> [e-mail] (Joe Francis) writes:
>The following macros have worked for me (and *please* let me know if they
>are faulty):
>#define
>ONSTACK(a)(((long)(a)<=*(long*)CurStackBase)&&((long)(a)>*(long*)ApplLim
>it))
>#define INHEAP(a)
>(((long)(a)>=*(long*)ApplZone)&&((long)(a)<*(long*)HeapEnd))

These macros will work for all current & normal Mac environments, and
they will also work with the Threads package published in Develop #6.
One might imagine that some future threads package might place stacks
inside of your heap, in which case it would not be so easy to determine
if an object is heap based or stack based.

With luck, though, we'll have language support for try/throw/catch before
then, and it won't be an issue.

Good article, by the way.

- --
=====================   ===========================   =====================
Greg Anderson           Apple Computer, Inc.            O    Ponnuki    O
Macintosh Bodhisattva   Macintosh System Software      O O  is  ideal  O O
[e-mail]       Finder Team                     O     shape     O
=====================   ===========================   =====================

---------------------------

End of C.S.M.P. Digest
**********************